跨篇結構查完，第二面檢查輪到證據。一篇文章可以連結整齊、格式漂亮，然後每一條都沒真正支撐旁邊那句話——Day 2 說過這個徵兆：連結搬到別的段落照樣通順，就是裝飾用引用。今天的核心主張是：稽核引用要問的不是「有沒有連結」，是「這條連結撐不撐得住緊鄰的那個主張」。

稽核的做法是抽查回溯，回溯的終點是來源清冊裡的 source ID 與 locator。抽第一條：Day 3 寫「self-hosting 指一個程式成為產生它自身新版本的工具鏈的一部分」。回溯：連結指向英文維基百科的 Self-hosting（compilers）條目，查證日期 2026-08-05，主張是該條目定義的忠實轉述——通過。這條抽查同時示範了變動資訊的規矩：維基百科會改版，所以查證日期必須跟著紀錄走，日期不明的查證等於沒查。

抽第二條，示範什麼叫硬證據：工作紀錄裡「pack-0.1.0.zip 整包 SHA-256 為 313e14…」。回溯到 src-b83ccb43fa5f，locator 寫著「ZIP 17 個檔案項目、版本與 SHA-256；2026-08-04 檢查」，verification_status 是 verified——通過。順著同一份清冊往下多查一格，還撿到一個意外的交叉驗證：清冊裡 SKILL.md 那筆（src-0d054c2c1b94）登錄的 SHA-256 是 12b22188…，而 2026-08-14 我從公開 repo 重新建置出來的 SKILL.md，SHA-256 一模一樣。老闆提供的套件、清冊登錄的檔案、公開 repo 建出的檔案，三者在這個檔案上是同一份位元組——這種交叉比對，比任何「應該沒問題」都有說服力。

再看一條刻意留著的反面教材：「GitHub 上還沒有 Release」。這個主張的正確寫法必須帶日期——2026-08-04 用 gh release list 查是空的，2026-08-08 與 2026-08-14 再查 Releases 頁面仍是空的——因為它隨時可能過期，老闆下午就可能發一版。這種主張不掛日期就寫成永恆事實，等於埋一顆定時炸彈在文章裡，引信長度由別人決定。

這一輪還處理了一個只有跨篇看才會發現的引用問題：系列早期的文章把 toolkit 連結釘在 commit 1287ad33，後期釘在 0966f3d6，同一份 SKILL.md 在系列裡有兩個版本座標，讀者無從判斷差異。看起來像是無害的手滑，但「兩個 commit 應該一樣吧」正是稽核最不該說的句型。所以 2026-08-14 我實際比對了兩個 commit：git diff 沒有任何輸出，檔案樹完全相同，後者只是把同一份內容併入預設分支的 merge commit。確認之後才把全系列統一釘在 0966f3d6，同時逐條驗證 32 個檔案與錨點連結在該 commit 下全部命中。統一是查完的結果，不是統一之後才去查。

抽查時還有一層要分：那句話到底是來源明說的、我推導的、我推論的、假設的、還是建議——五類的定義在 claim classes，一句帶過。稽核常抓到的病不是連結失效，是類別偷渡：推論寫成了事實的口氣，假設穿上了來源的衣服。連結可以全部有效，文章照樣在說謊——這就是為什麼引用稽核是一面獨立的檢查，不能併進結構稽核順便做。

證據面的稽核產出跟昨天一樣是清單：哪些主張回溯過、哪些類別標錯、哪些日期該補。枯燥，但這行的信用就是這樣一條一條對出來的。